Digital multimedia contact center

ABSTRACT

A tiered service model for a digital multimedia contact center assigns an entering contact to an initial service tier based on routing criteria for the contact and may escalate or de-escalate the contact to a different service tier if the routing criteria chances. The routing criteria is initially determined based on a media type associated with the contact. The digital multimedia contact center contains a set of media routers, each of which passes a contact of a particular media type to a workflow engine which executes workflows to direct the processing of contacts at service tiers that require agent activity. Agents are allocated to contacts by a dynamic automate contact distributor and the appropriate media router is used to route the contact to an agent. The workflow engine also executes workflows for agents to control the allocation of agents to contacts.

FIELD OF THE INVENTION

This invention relates generally to the operations of a customer contactcenter, and more particularly to a contact center that processescontacts having different media types.

COPYRIGHT NOTICE/PERMISSION

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever. The following notice applies to the software and dataas described below and in the drawings hereto: Copyright © 1999, NUASISCorporation, All Rights Reserved.

BACKGROUND OF THE INVENTION

Call centers are typically used by organizations to service customers.Traditionally, customers called into a call center using POTS (plain oldtelephone service) but more and more organizations are implementingother types of media access such as email, voice mail, Web browsing,etc. to expand the ways by which their customers may contact them.Current attempts to integrate the different media into a single callcenter have proved ineffective because of the disparate nature of thedifferent media types. For example, telephone calls usually average afew hundred a day, while emails often run into thousands a day, anddaily hits on a Web site frequently number hundreds of thousands.Additionally, the response time expected by the customer varieddepending on the media type used.

One approach processes a contact based on its media type. This approachignores the fact that the same media type can be used for differenttypes of service. For example, a customer that calls a manned help linerequires different handling than a customer calling an interactive voiceresponse system. Another approach is to handle all contacts identically,regardless of media type. This approach fails to account for thedifferent number of contacts and different expected response times for acustomer independent of the various media types. Thus, a call centerthat processes all calls as requiring an immediate response quicklybecomes overloaded with emails. Furthermore, both of these approachesinvolve extensive modifications to the systems that underlie the callcenter, such as the email system, the telephony system, etc., so thatthe many of the original features and benefits of the underlying systemsare lost. Additionally, while some previous implementations appear tointegrate analog contacts, such as voice calls, and digital contacts,such as email, the actual processing of the two types of contacts isseparated.

SUMMARY OF THE INVENTION

The above-mentioned shortcomings, disadvantages and problems areaddressed by the present invention, which will be understood by readingand studying the following specification.

A tiered service model for a digital multimedia contact center assignsan entering contact to an initial service tier based on routine criteriafor the contact and may escalate de-escalate the contact to a differentservice tier if the routing criteria changes. The routing criteria isinitially determined based on a media type associated with the contact.The digital multimedia contact center contains a set of media routers,each of which passes a contact of a particular type to a workflowengine. The workflow engine starts a workflow for the contact and callsa dynamic automatic contact distributor to allocate an agent to thecontact if the service tier of the contact requires agent activity. Theworkflow engine returns an identifier for the allocated agent to themedia router, which then routes the contact to an agent desktop for theagent. The agent desktop presents the contact to the agent forprocessing. The workflow engine also creates a workflow for an agent tocontrol the allocation of the agent to contacts.

The digital multimedia contact center operates in conjunction withexisting systems dedicated to a particular media type without requiringmajor modifications to those systems, thus leveraging the functionalityof the existing systems. For example, emails are generally handled atone service tier by the standard operations of a conventional emailsystem unless specially marked in the email system as having beenescalated to a higher service tier. Similarly, voice calls are initiallyassigned to a high service tier for handling by an agent but can bede-escalated to a lower service tier and routed to an existinginteractive voice response system if appropriate. Thus, the digitalmultimedia contact center handles contacts in accordance with thecontact's required level of service instead of relying solely on themedia type to determine the necessary processing. Furthermore, thedigital multimedia contact center implements the most appropriateprocessing methodology for the number of contacts expected at eachservice tier.

The present invention describes systems clients, servers, methods, andcomputer-readable media of varying scope. In addition to the aspects andadvantages of the present invention described in this summary furtheraspects and advantages of the invention will become apparent byreference to the drawings and by reading the detailed description thatfollows.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating a three-tiered service model for adigital multimedia contact center of the present invention;

FIG. 2 is a diagram illustrating an embodiment of a system architectureunderlying the digital multimedia contact center model shown in FIG. 1;

FIGS. 3A-C are diagrams illustrating the processing of media-specificcontacts within the architecture of the digital multimedia contactcenter shown in FIG. 2;

FIGS. 4A-C are flowcharts of method to be performed by voice componentsin the embodiment of the digital multimedia contact center shown in FIG.2;

FIGS. 5A-C are flowcharts of method to be performed by escalated emailcomponents in the embodiment of the digital multimedia contact centershown in FIG. 2;

FIGS. 6A-C are flowcharts of method to be performed by collaborationcomponents in the embodiment of the digital multimedia contact centershown in FIG. 2;

FIGS. 7A-C are flowcharts of method to be performed by agent componentsin the embodiment of the digital multimedia contact center shown in FIG.2;

FIG. 8A is a diagram of a contact detail data structure for use in animplementation of the invention;

FIG. 8B is a diagram of an agent data structure for use in animplementation of the invention;

FIG. 9A is a diagram of a workflow engine for use in an implementationof the invention;

FIG. 9B is a diagram of an asynchronous workflow executed by theworkflow engine of FIG. 9A;

FIG. 10A is a diagram of one embodiment of an operating environmentsuitable for practicing the present invention; and

FIG. 10B is a diagram of one embodiment of a computer system suitablefor use in the operating environment of FIG. 10A.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of embodiments of the invention,reference is made to the accompanying drawings in which like referencesindicate similar elements, and in which is shown by way of illustrationspecific embodiments in which the invention may be practiced. Theseembodiments are described in sufficient detail to enable those skilledin the art to practice the invention, and it is to be understood thatother embodiments may be utilized and that logical, mechanical,electrical, functional and other changes may be made without departingfrom the scope of the present invention. The following detaileddescription is, therefore, not to be taken in a limiting sense, and thescope of the present invention is defined only by the appended claims.

The detailed description is divided into four sections and a conclusion.In the first section, a system level overview of the invention ispresented. In the second section, methods for an embodiment of theinvention are described with reference to flowcharts. In the thirdsection, a particular Internet Contact Center (iCC) implementation ofthe invention is described. In the final section, an operatingenvironment in conjunction with which embodiments of the invention maybe practiced is presented.

System Level Overview

A system level overview of the operation of an embodiment of theinvention is described by reference to FIGS. 1 and 2.

FIG. 1 illustrates a three-tiered service model 100 for a digitalmultimedia contact center. As shown, there are three service tiers:self-service tier 101, deferred service tier 103, and immediateassistance tier 105. Contacts accessing the center at the self-servicetier 101 do not require the assistance of an agent at the contactcenter, while contacts being serviced at the deferred tier 103 and theintermediate assistance tier 105 do require agent activity. A contactaccessing the center at deferred tier 103 is presented to an agent in a“pull” model as a background task on the agent's computer desktop. Anagent pulls a deferred contact for processing when there are noimmediate assistance contacts to process. A contact at the immediateassistance tier 105 is presented in a “push” model as a foreground task.One immediate assistance contact is pushed to the agent's desk at anyone time and in such a way that it is obvious to the agent that thiscontact must be handled immediately. As a particular contact ispresented, any related customer information is also shown. Thecomponents for the different tiers are designed to handle differentmagnitudes of contacts. The self-service tier components will processorders of magnitude more contacts than the deferred tier components,which will process orders of magnitude more contacts than the immediateassistance tier components.

A contact entering the contact center is initially assigned to one ofthe three tiers based on the type of media used by the contact inaccessing the contact center. The embodiment shown in FIG. 1 is furtherdescribed with reference to three media types: voice calls, emails, andWorld Wide Web, although the invention is not so limited. Voice callsare initially routed to the immediate assistance tier 103, emails areinitially routed to the deferred tier 102, and Web contacts areinitially routed to the self-service tier 101. Subsequent routing may beperformed that escalates or de-escalates the contact to another tier(shown as arrows in FIG. 1). The subsequent routing can be based on oneor more routing criteria, including factors defined by the contactcenter owner or subscriber, such as priority, access phone numbers, andtime-out periods, and environmental factors such as contact activity.The routing criteria associated with a contact may change as the variouscomponents in the contact center process the contact. For example, ifthe routing criteria of a contact passes a pre-defined threshold, thecontact may be escalated or de-escalated. Thus, an email is escalated(arrow 111) to the immediate assistance tier 103 if it has not beenanswered when a “time-to-reply” period elapses. A voice call isinitially routed to the immediate assistance tier 103 but isde-escalated (arrow 115) to the deferred tier 103 if the caller choosesto leave voice-mail, or de-escalated (arrow 113) to the self servicetier 103 if the contact is sent to an interactive voice response (IVR)system for more processing. A self service Web contact can be escalated(arrow 107) into the immediate assistance tier 103 by through “Click toChat” or “Click to Talk” buttons available on the Web site, or escalated(arrow 109) to the deferred tier 103 if the contact chooses to send anemail instead. Details of the escalation and de-escalation of each mediatype is described in more detail in conjunction with the flowcharts inthe next section. Furthermore, although the exemplary embodiments focuson voice, email, and Web contacts for ease in understanding, it will beappreciated that the invention encompasses all potential analog anddigital media types, including fax, “faxback,” video, etc., in additionto being extensible to other WANs and to LANs. It will also beappreciated that the contact is not limited by its initial media typeso, for example, the contact and agent in a collaboration session couldbe also taking by phone, an email message could generate a return fax orphone call, or the expiration of a time-out on a collaboration requestmight generate an email message to the contact promising a responsewithin a set time period.

The three-tier service model 100 illustrated in FIG. 1 operates within adigital multimedia contact system, one embodiment of which is shown inFIG. 2. The system architecture for contact center 200 is based on aworkflow engine 201 that directs the activities of the agents in thecenter using workflow steps. A contact workflow is initiated by eventsthat are routed into one of a set of workflow subsystems 205 by one of aset of media routers 221. Each media router 221 and each correspondingworkflow subsystem 205 are dedicated to a contact media type. An agentworkflow is initiated by events routed into an agent subsystem 219 by anagent desktop component 229. Events that trigger a workflow include anew call arriving at the contact center or an agent logging in. Theworkflow for a contact remains active until the contact is terminated;the workflow for an agent remains active until the agent logs out of thecontact center 200.

The workflows are executed by workflow logic 207. Events are passedbetween the workflow logic 207 and the workflow subsystems 205 by amessage passing layer 203. The events can also modify the execution flowof existing contact or agent workflows.

When executed by the workflow logic 207, a workflow for an immediateassistance contact causes a dynamic ACD (automatic contact distributor)241 to allocate an agent to the contact. The allocation is alsoreflected in the agent's workflow. The operation of the dynamic ACD 241is described in further detail below.

A contact coming into the contact center 200 is initially classified inaccordance with a set of previously defined classifications, e.g.,Sales, Customer Service, Support, etc., by the appropriate workflowsubsystem 205. Additional information is also gathered to determine theoptimal routing of the contact. Information that narrows down the set ofagents to which a contact can be routed is referred to as “contactrequirements.” Examples of contact requirements include productknowledge, language fluency, and previous communication with the contact(each contact is considered a new one). Origin and destinationinformation now is consistently collected from all media types, such ascalling phone number and called phone number for voice calls. Subjectinformation may also be collected from voice contacts based on responsesto IVR menu options.

A voice router 223 provides an interface between a voice subsystem 213and a conventional digital telephony system (voice server 222), such asthe DOT (Distributed Open Telephony) server from Tundo Corporation thathandles IP (Internet Protocol) calls. The voice subsystem 213 starts aworkflow when a call arrives at the contact center 200 and communicatesa request to the voice server 222 to redirect the call to an agent (orto voice mail or IVR) as determined by the workflow. The voice server222 receives digital voice calls (referred to as voice-over-IP or VoIP)directly from a digital wide-area network (WAN) 220, such as theInternet, or via a gateway 251, such as the Tundo Gateway, that convertsanalog voice calls 253 to VoIP calls. The gateway 251 also converts VoIPcalls from the digital telephony system 222 into analog voice signalsfor transmission back to the caller.

A conventional email system (email server 226), such as the Cisco EmailManager from Cisco Systems, processes deferred contacts received fromthe WAN 220. The email system uses its own in-line rules engine forprocessing incoming email and placing it into mailboxes to be accessedby the agents as background tasks. The agents retrieve deferred contactsfrom these mailboxes explicitly. An email escalator 227 provides aninterface between an email subsystem 217 and the conventional emailsystem for emails that are escalated from deferred to immediateassistance. The email escalator 227 periodically reviews the mailboxesfor pending emails that meet per-determined criteria for escalation,such as time-to-reply or customer value parameters. It then collectsinformation about the email (customer, priority etc.) and passes this tothe email subsystem 217. In one embodiment, the emails are evaluated inchronological order and the emails that meet the escalation criteria arefurther broken down by classification and within a particularclassification, the email is passed to the email subsystem 217 on afirst-in, first-out basis.

The email subsystem 217 determines if the contact is entitled to beescalated to an immediate assistance contact based on the contactinformation and starts a contact workflow if it is. When the workflowsucceeds in routing the email to an agent, the agent address is returnedto the email escalator 227, which passes it to the email subsystem 217for actual routing to the agent. In an embodiment in which voice mail isrouted to an agent as an audio attachment to an email, the emailescalator 227 also serves to escalate voice mails to the immediateassistance tier if appropriate.

A conventional Web server 224 processes self-service contacts thatoriginate from the WAN 220. Such a server can offer browsing andsearching capabilities for a knowledge base, or a set of FAQs(frequently asked questions). A collaboration router 225 provides aninterface between a collaboration subsystem 215 and a conventionalcollaboration system, such as the Cisco Collaboration Server from CiscoSystems, that executes on, or in conjunction with, the Web server 224.Web pages on the Web server 224 are modified to include “Click toChat/Talk” buttons to connect to the collaboration system. When thebutton is clicked by a Web contact, the collaboration system sends anevent to the collaboration router 225, which in turns sends an event tothe collaboration subsystem 215. The collaboration subsystem 215determines if the contact is entitled to be escalated to an immediateassistance contact and initiates a contact workflow if so. Once thecollaboration request has been assigned to an agent, the agent addressis passed back to the collaboration router 225 for actual routing. Otheragents may be included in the collaboration session as necessary.

An agent subsystem 219 provides an interface between one or more agentdesktops 229 and the workflow logic 207 for agent events. When notifiedof an agent login by the corresponding agent desktop 229, the agentsubsystem 219 validates the agent before starting an agent workflow thatdescribe the agent's work process until the agent logs out. The agentdesktop 229 notifies the agent subsystem 219 of all agent state changes.The agent subsystem 219 is also responsible for watching the agent'sphones for outbound call events. It passes this information to theworkflow logic 207 to ensure the agent state is changed to “busy.” Inaddition, when an agent initiates a call, the agent subsystem 219 sendsan “outbound call” event to the agent's workflow so that agent-initiatedcontacts can be tracked.

The agent desktop 229 controls the presentation of tasks on an agent'sdesktop. The tasks originate from the multiple conventional systems withwhich the contact center 200 interfaces as previously described, as wellas from the workflow engine 201. Each of the conventional systems hasits own user interface. Monitoring tools may also be available tocertain agents, such as those providing statistics on the operation ofthe contact center and individual agents. The agent desktop 229integrates the separate user interfaces into a single coherent interfacethat presents the agent with immediate assistance contacts as foregroundtasks and deferred contacts as background tasks. Thus, for example, theforeground mode integrates the telephony interface, the collaborationinterface, and the email interface (for escalated emails). Similarly,the background mode integrates the email interface (for non-escalatedemails and other deferred contacts, such as voice mail, fax, forms,etc.) and the monitoring tools, for example. The agent desktop 229 alsointegrates with any existing customer relation management application toprovide customer information to the agent for the foreground andbackground tasks. The connections between the agent desktops 229 and theconventional systems 222, 224, 226 are not shown in FIG. 2 for clarityin illustration.

In an alternate embodiment not shown, the agent desktops 229 do notcommunicate directly to the agent subsystem 219 but are managed througha desktop manager component that handles concurrent requests fromdesktops and routes responses. To concurrently handle multiple desktops,a client portion of the desktop manager executes within each agentdesktop component and communicates with a server portion that queuesevents arriving from the agent subsystem 219 and sends them to theappropriate desktop in response to polls from the desktops. Executingthe server portion of the desktop manager on a machine separate fromthat executing the agent subsystem, provides additional scalingcapabilities to the contact center.

The relationship among the components of the contact center 200described so far is most easily understood through an example. When ananalog voice call 253 is received by the gateway 251, it is converted toa VoIP call and directed by the voice server 222 to a voice media router223. The voice media router 223 informs the voice subsystem 213 of theincoming contact and the voice subsystem 213 creates a workflow for thecontact. Assuming the contact is to remain at the immediate assistancetier 103, the workflow requests the dynamic ACD 241 allocate an agent tothe contact. The dynamic ACD 241 passes the agent information back tothe voice subsystem 213, which then sends the agent and contactinformation to the voice router 223. The voice router 223, in turn,sends the information to the voice server 222 for routing. The voiceserver 222 transfers the contact to the appropriate agent desktop 229 asa foreground task.

Returning now to FIG. 2, the workflow engine 201 also contains adatabase 231 of contact 233 and agent records 235. A databaseunification layer 261 combines the information in the database 231 andinformation maintained by the voice 222, Web 224, and email 226 serversinto a coherent view of the contact center. The contact and agentworkflows query and update the database 231 through a database subsystem211 that converts workflow requests into calls for the databaseunification layer 261. In an alternate embodiment not shown in FIG. 2,the contact and agent workflows query the database unification layer 261directly. In yet another alternate embodiment, the database unificationlayer is incorporated into the database subsystem 211.

The database unification layer 261 has access to, and is accessible by,all the other components of the contact center to allow reporting andanalysis of the activities of the contact center regardless of the mediatype used by the contacts. The connections between the databaseunification layer 261 and the other components are not shown in FIG. 2for clarity in illustration. The information can be retrieved throughthe database unification layer 261 by a monitoring tool (not shown) tographically and/or numerically illustrate the state of the contactcenter (number of contacts awaiting service, how many agents are onbreak, etc). For instance, the monitoring tool may display the number ofunserviced contacts broken down by classification. Additionally, aconventional reporting application can be employed to obtain informationthrough the database unification layer 261 for standardized reports.Agents, supervisors and managers may each have access to a set of suchreports to gauge the efficiency of the contact center, a group, orindividual agent. The database unification layer 261 also provides forthe collection of billing information and for the tracking of contactsthrough the contact center, both across media types.

In the embodiment shown in FIG. 2, the dynamic ACD 241 uses unorderedlists of waiting contacts 237 and available agents 239 to match acontact with an agent. The workflow engine 201 causes the dynamic ACD241 to create and manage the unordered lists of contacts 237 and agents239. Although shown as separate from the database 231 in FIG. 2, it willbe appreciated that the unordered lists 237, 239 may be databasestructures that are managed by the database subsystem 211 as instructedby the workflow engine 201 and the dynamic ACD 241.

As previously described, contact requirements (e.g., product knowledge,language fluency, previous communication) are used to determine the setof agents to which a contact can be routed. Information used to decidethe appropriateness of an agent within the set is referred to as “agentattributes” and may include such parameters as seniority length of timewaiting for a contact. Furthermore, agents may be dedicated to one ormore contact classifications. When an immediate assistance contactrequests an agent, the dynamic ACD 241 searches for an appropriate agentfrom the list 239 of available agents by filtering the agents againstthe contact classification and any requirements, and prioritizes theresulting agents according to their attributes. If an agent isavailable, the dynamic ACD 241 passes the information for the agent backto the appropriate subsystem to route the contact to the agent andremoves the agent from the available agent list 239. If no appropriateagent is available, the contact is entered into the waiting contact list237 until an appropriate agent becomes available to take the contactSimilarly, when an agent requests a contact, the waiting contact list237 is filtered by classification and “agent requirements” (e.g., mediatype, territory) and prioritized according to contact attributes such astime in queue and business value. The matching process is invoked by astep in the contact workflow for an immediate assistance contact or inthe agent workflow for an available agent as explained further below.

As illustrated in FIG. 2, there may be multiple instances of each of themedia routers 221. There is also an instance of the agent desktop 229running on each agent workstation in the contact center. Although only asingle set of workflow subsystems 205 is shown, it will be appreciatedthat workflow engine 201 may contain multiple instances of one or moreof the workflow subsystems 205 depending on workload. Additionally,multiple workflow engines 201 may be present within a contact center200.

Furthermore, the architecture permits distribution of the variouscomponents among multiple computers, thus enabling scalability of thecontact center 200. As described previously, each component providesservices for other components. For instance, the dynamic ACD 241provides an agent allocation service and the collaboration subsystem 215provides a collaboration workflow service. In one embodiment, a servicemanager (not shown) provides a central location for registration anddiscovery of the contact center service providers. When a componentneeds a service (such as the initialization of a workflow), it calls theservice manager to find the location of that service. The servicemanager reviews a list of all registered providers of that service andselects the appropriate providers (e.g., shortest routing to requester).Finally it chooses the best provider based on the unused capacity ofeach service. Thus, the contact center 200 may continue to startservices on new or existing machines as necessary to deal with itsworkload.

The system level overview of the operation of an embodiment of theinvention has been described in this section of the detaileddescription. A tiered service model that allows the escalation andde-escalation of a contact has been described, alone with its operationwithin a digital multimedia contact center. The digital multimediacontact center handles contacts in accordance with the contact'srequired level of service instead of relying solely on the media type todetermine the necessary processing. Because different levels of serviceincur different quantities of contacts, different processingmethodologies are appropriate within the contact center. Thus, workflowsare used to handle immediate assistance contacts regardless of mediatype because a workflow engine excels at processing relatively smallnumbers of contacts in real-time. A workflow engine also gives thesubscriber fine-grained control over the handling of the high prioritycontacts that require immediate assistance. On the other hand, deferredcontacts number least an order of magnitude greater than immediateassistance contacts and are handled most efficiently through an inlinerule engine such as commonly implemented in an email (and/or voice mail)system. Finally, because the greatest number of contacts areself-service contacts which require no agent intervention, processingtechniques such as interactive voice response, automatic email response,and knowledge base/FAQ logic on Web servers are used.

While the invention is not limited to any particular number of servicetiers, the invention has been described in terms of a three tier model.The invention has further been described using an example that mixesvoice calls, emails, and Web contacts within the same contact center butthe invention is not so limited. Additionally, the invention can bepracticed with any underlying architecture that allows the escalationand de-escalation of contacts through a tiered service model.

METHODS OF EMBODIMENTS OF THE INVENTION

In the previous section, a system level overview of the operations ofembodiments of the invention was described. In this section, theparticular methods of one embodiment of the multimedia copy contactcenter 200 are described in terms of computer software with referencewith a series of flowcharts and also a series of tier diagrams. Theflowcharts and tier diagrams are grouped according to related componentswithin the contact center. Thus, FIG. 3A and flowcharts FIGS. 4A-Cillustrate the processing of the voice components. FIG. 3B andflowcharts 5A-C illustrate the processing of the email escalatorcomponents. FIG. 3C and flowcharts 6A-C illustrate the processing of thecollaboration components. The processing of the agent components areillustrated only through flowcharts in FIGS. 7A-C.

The methods to be performed by a computer constitute computer programsmade up of computer-executable instructions. Describing the methods byreference to a flowchart enables one skilled in the art to develop suchprograms including such instructions to car out the methods on suitablyconfigured computers (the processor of the computer executing theinstructions from computer-readable media) acting as one or more of thecomponents of the contact center 200 in FIG. 2. The computer-executableinstructions may be written in a computer programming language or may beembodied in firmware logic. If written in a programming languageconforming to a recognized standard, such instructions can be executedon a variety of hardware platforms and for interface to a variety ofoperating systems. In addition, the present invention is not describedwith reference to any particular programming language. It will beappreciated that a variety of programming languages may be used toimplement the teachings of the invention as described herein.Furthermore, it is common in the art to speak of software, in one formor another (e.g., program, procedure, process, application, module,logic . . . ) as taking an action or causing a result. Such expressionsare merely a shorthand way of saying that execution of the software by acomputer causes the processor of the computer to perform an action or aproduce a result.

As shown in FIG. 3A, the voice components receive a voice phone call anddirect it to either an agent for immediate assistance 305 or to aninteractive voice response system 301 for self-service. If directedinitially to an agent 305, the workflow engine may de-escalate thecontact (represented by arrow 311) to voice mail 303 if an agent is notavailable within a given period of time. In addition, the workflowengine may de-escalate an immediate assistance contact (represented byarrow 313) to interactive voice response (IVR) 301 if the call priorityis less than a pre-determined amount or if the caller choosesself-service. A self-service contact may be escalated by a voice mailmanager (represented by arrow 309) if the user chooses to leave voicemail. Alternatively, when a self-service contact requests activeassistance from an agent, the workflow engine 201 and the dynamic ACD241 escalate the contact into the immediate assistance 305 asrepresented by arrow 307. In an embodiment in which the voice mailrecording is attached to an email for subsequent processing by an agent,the email with the voice mail attachment may be escalated through acombination of the email escalator, the workflow engine, and the dynamicACID (represented by arrow 315) as explained below in conjunction withFIGS. 3B and 5A-C.

Turning now to FIGS. 4A-C, the flowchart in FIG. 4A illustrates the actsperformed by the voice router 223 component when executing a voicerouter method 400. The voice router method 400 receives notification ofa call from the voice server 222 (block 401). As part of the informationreceived from the gateway, the voice router method 400 receives theoriginating and destination phone numbers for the call, which it thensends to the voice subsystem 213 (block 403). The voice subsystemdetermines how to route the call, as will be described further below,and sends the routing information to the voice router. The voice routermethod 400 receives the routing information (block 405) and then sendsthe routing information to the voice server 222 for routing (block 407).

Turning now to FIG. 4B, a voice subsystem method 420 executed by thevoice subsystem component 213 is described. The voice subsystem method420 receives the originating and destination phone numbers from thevoice router (block 421), collects additional contact information andcreates a contact record for the contact (block 423). The voicesubsystem method 420 then evokes an appropriate voice workflow for thecontact from the workflow engine 201 (block 425). One of the stepswithin the voice workflow will be the determination of service tier,i.e., immediate assistance or a self-service. Assuming the contact is aself-service contact, the voice subsystem method 420 receives an IVRrequest from the voice workflow at block 427 and then sends the IVRinformation to the voice recorder at block 429 so that the voice routerwill route the voice call to interactive voice response. On the otherhand, if the workflow determines that the contact is an immediateassistance contact (block 431), the voice subsystem method 420 receivesan agent request from the workflow and requests an agent from thedynamic ACD (block 433) in response. The dynamic ACD attempts to matchan agent with the contact as previously described. Assuming no agent isavailable within a pre-determined period of time, the workflow causesadditional options to be presented to the contact. In one instance, thecontact may choose to be routed to voice mail, at which point theworkflow engine sends a remove-contact event to the voice subsystemmethod 420, which is received at block 435. In response, the voicesubsystem method 420 requests that the contact be removed from the listby the dynamic ACD (block 437). If, however, an agent is available, thedynamic ACD sends the agent information to the voice subsystem method420, which in turn sends the agent information to the voice router(block 439) so that the voice router may appropriately route the contactto the chosen agent. The voice subsystem method 420 continues to monitorthe contact to determine if the call is answered within a reasonableperiod of time (block 441). If it is, then the voice subsystem method420 injects a handle-agent event into voice workflow at block 443 sothat the workflow will continue to handle the contact as explainedfurther below. Alternatively, if the call is not answered, the voicesubsystem method 420 returns to block 433 and requests another agentfrom the dynamic ACD. In one embodiment, the voice subsystem method 420generates events which create and update contact information regardingthe voice call in the database 231.

FIG. 4C illustrates one embodiment of a voice workflow 450 that isexecuted by the workflow logic 207 for a voice contact. When the voiceworkflow 450 is initiated, it obtains contact information through theIVR process at block 451 (shown in phantom) if it is unable to determinethe contact information from the originating phone number. The contactis classified based on its information at block 453. A determination ismade as to the level of service to be given to this contact (block 455).If the contact is not entitled to immediate assistance, the voiceworkflow 450 requests the contact be routed to the IVR system by thevoice subsystem (block 477). The voice workflow 450 continues to monitorthe contact because a contact at the IVR self-service tier 301 maychoose to leave a voice mail or wait for an agent during the IVR sessionby inputting certain digits. The input digits are captured as events bythe voice workflow 450 at block 479 and, depending on the event, thevoice workflow 450 escalates the contact to the deferred assistance tier303 by transferring the contact into the voice mail system (block 471)or to the immediate assistance tier 305 by requesting an agent for thecontact (block 457). In one embodiment, the email system manager servesas the voice mail manager and the processing represented by block 471 isperformed by the workflow. The workflow records the contact's message,attaches the recording to an email message addressed to a generalmailbox, and sends the email to the email subsystem 217 for transmissionto the email server 226.

If the contact is entitled to immediate assistance, an agent isrequested from the voice subsystem at block 457 and the caller is put onhold to wait for events from the voice subsystem (block 459). If ahandle-agent event is injected into the voice workflow 450 by the voicesubsystem because an agent allocated to this contact has answered thephone, the handle-agent event is detected at block 461 and contactinformation is sent to the voice subsystem (block 463). The voiceworkflow 450 then loops waiting for events responding appropriately tothose events, including updating the contact record, until the call isterminated as represented by block 465. Once the call is terminated, thevoice workflow 450 sends a left-session event to the agent subsystem atblock 467 that causes the agent to become available to receive a newcontact.

If the contact chooses to be sent to voice mail prior to being routed toan agent (block 461), the voice workflow 450 sends a remove-contactevent to the voice subsystem at block 469 to remove the contact from thelist managed by the dynamic ACD. The voice workflow 4501 transfers thecontact to the voice mail manager to record the message (block 471) andterminates the call after the messages is recorded (block 473). Thevoice mail is then sent to a general mailbox to be acted upon by anagent at a later point (block 475). In one embodiment, the voice messageis attached to an email message and placed into the mailbox by the emailsystem.

Referring now to FIG. 3B and FIGS. 5A-C, the email escalator componentof the multimedia contact center 200 is described. As shown in FIG. 3B,a deferred email 323 is escalated into a high priority email 325 througha combination of the email escalator, the workflow engine, and thedynamic ACD (represented as arrow 327). Alternatively, an email messagemay be handled through an automatic response option in the conventionalemail system and such an email is de-escalated by the email server 226(represented as arrow 329) into an auto response contact 321. Asautomatic response options are common in conventional email systems, thede-escalation process is not further described.

FIG. 5A illustrates an email escalator method 500 performed by the emailescalator 227. The email escalator method 500 constantly reviews theemail system mailboxes or queues (block 501) to determine if any pendingemails should be escalated based on factors previously described. If anemail is to be escalated (block 503), it is placed in a high priorityqueue (block 505) and the email information is sent to the emailsubsystem 217 at block 507. As will be explained in conjunction withFIG. 5B, the email subsystem 217 matches the contact to an agent andreturns the agent identifier, which is received by the email escalatormethod 500 at block 509. The email escalator method 500 routes the email(via the email system) to the agent desktop (block 511) as a foregroundtask. In one embodiment, the email is presented on the desktop alreadyopened. Once the agent has determined that he or she is ready to handlethe email, the email escalator method 500 receives an agent-ready eventfrom the agent desktop (block 513) and sends that event to the emailsubsystem at block 515. The agent workflow will not assign the agent toany other contacts until the email is handled. In another embodiment,the email escalator method 500 instructs the email subsystem to identifyan email that is close to being escalated and to give the agent a visualclues such as color or a special icon, that the email must be handledimmediately.

A component acting as the email subsystem 217 executes a email subsystemmethod 520 to perform the functions illustrated in FIG. 5D. The emailsubsystem method 520 receives the email information from the emailescalator at block 521 and invokes the workflow logic 207 at block 523.In one embodiment, when the email subsystem method 520 receives theemail information at block 523, it creates the contact record for theemail and marks it as escalated. In an alternate embodiment, the emailmanager a contact record is created for each email received at thecontact center and the email subsystem method 520 marks the existingcontact record as escalated at block 523.

The workflow requests an agent from the email subsystem at block 525.The email subsystem method 520 requests the agent from the dynamic ACDat block 527. When an agent is allocated to the contacts the agentidentifier is returned from the dynamic ACD to the email subsystemmethod 520, which, in turn, at block 529 returns the agent identifier tothe email escalator to cause the contact to be routed to be identifiedagent. The email subsystem method 520 injects a handle-agent event intothe email workflow at block 531 in response to receiving the agent-readyevent from the email escalator. In one embodiment, the email subsystemmethod 520 generates events which create and update contact informationregarding the escalated email in the database 231.

A method 540 for a contact workflow for an escalated email isillustrated in FIG. 5C. When the escalated email workflow 540 begins, itrequests an agent from the email system at block 541, which causes theevents previously described to occur. When the escalated email workflow540 receives the handle-agent event at block 543, the workflow sends theemail to the agent desktop at block 545 via the agent subsystem 219. Asthe agent is working with the escalated email message, the agent maygenerate events that cause the escalated email workflow 540 to performcertain functions, including updating the contact record, representedgenerally at block 547. When the agent is finished with the escalatedemail message, the escalated email workflow 540 sends a left-sessionevent to the agent subsystem at block 549.

FIG. 3C illustrates the escalation that is performed for a contact thatinitially appears at the contact center 200 through a self-service Website 341. By choosing to send an email, the contact can be escalated(represented by arrow 349) through the email manager into a deferredemail contact 343. Alternatively, if the contact clicks on acollaboration/chat button, it is escalated by a combination of theworkflow engine and the dynamic ACD (represented by arrow 347) into animmediate assistance contact 345. As the sending of email is handled bythe conventional email system, the escalation from a self-servicecontact 341 into a deferred email contact 343 is not further discussed.

Turning now to FIG. 6A-C, the escalation of a contact from aself-service Web contact 341 to an immediate assistance collaborationcontact 345 is described beginning with collaboration router method 600performed by the collaboration router 325. The collaboration routermethod 600 receives the contact information from the web server (block601) and sends the contact information to the collaboration subsystem215 (block 603) to have an agent allocated to the contact. When thecollaboration router method 600 receives the agent identifier from thecollaboration subsystem at block 605, then routes the collaborationsession to the agent desktop for the identified agent (block 607) viathe collaboration server.

A collaboration subsystem method 620 executed by the collaborationsubsystem 215 is next described in conjunction with FIG. 1D. Thecollaboration subsystem method 620 receives the contact information fromthe collaboration router at block 621 and invokes a collaborationworkflow for the contact at block 623. A contact record for thecollaboration contact is also created at block 623. The collaborationsubsystem method 620 receives an agent request from the collaborationworkflow (block 625) and requests an agent from the dynamic ACD (block627). When the dynamic ACD returns the agent identifier to thecollaboration subsystem method 620, it returns the agent identifier tothe collaboration router (block 629) for routing the collaborationsession to the appropriate agent's desktop. The collaboration subsystemmethod 620 also injects a handle-agent event into the collaborationworkflow at block 623. Events resulting from the collaboration sessionare injected into the workflow by the collaboration subsystem method 620when the session terminates (block 633). In one embodiment, thecollaboration subsystem method 620 generates events which create andupdate contact information regarding the collaboration session in thedatabase 231.

Turning now to FIG. 6C, a collaboration workflow method 640 that isexecuted by the workflow logic 207 as a collaboration workflow for acontact is described. When the collaboration workflow method 640 begins,it requests an agent from the collaboration subsystem at block 641. Thecollaboration workflow method 640 receives a handle-agent event from thecollaboration subsystem at block 643. The handle-agent event informs theworkflow that the agent is now ready for the collaboration session andcollaboration workflow method 640 sends the contact information to theagent desktop (block 645) via the agent 219 subsystem. The collaborationworkflow method 640 updates the contact record with the events receivedfrom the collaboration subsystem when the session is terminated (block647). The collaboration workflow method 640 also sends a left-sessionevent into the agent subsystem at block 649.

The methods used by the multimedia contact center 200 for agents are nowdescribed with reference to the flowcharts in FIGS. 7A-C. FIG. 7Aillustrates an agent desktop method 700 that presents tasks on an agentdesktop 229. The agent desktop method 700 receives a login event when anagent logs into the contact center (block 701). The agent desktop method700 sends the agent information into the agent subsystem 219 at block703. As part of their processing, the agent subsystem 219 and the agentworkflow 207 make the agent available for contacts. The agent desktopmethod 700 waits for messages from the agent and the agent subsystem atblock 705. If the agent desktop method 700 receives the routed contacts(block 707), it passes the contact information onto to appropriateunderlying system (such as the email system and the collaborationsystem) at block 709. When the appropriate system has terminated thecontact, the agent desktop method 700 receives a wrap-up event from theagent subsystem (block 711), which causes it to put the agent into awrap-up state (block 713). The agent desktop method 700 sends anend-of-wrap up event to the agent subsystem at block 715 when the agenthas finished the contact wrap up procedures.

The agent desktop method 700 also handles the transition of the agentinto various states such as break, logout, etc. If the agent isrequesting a break (block 717), the agent desktop method 700 sends thebreak request to the agent subsystem (block 719), which forwards it ontothe agent workflow for a decision (as described further below). If thebreak request is allowed (block 721), the agent desktop method 700 waitsfor the agent to return from break and sends an off-break event to theagent subsystem to inform it that the agent is again available (block723).

If the agent is logging out (block 725), the agent desktop method 700sends an agent-logout event into the agent subsystem at block 729. Allother messages are sent to the agent subsystem at block 727. One ofskill in the art will readily understand the processing necessary totransition the agent into other states without further illustration.

Referring now to FIG. 7B, an agent subsystem method 730 executed by thecomponent acting as the agent subsystem 219 is described. The agentinformation is received from the agent desktop at block 731 when theagent logs into the contact center. The agent subsystem method 730invokes an agent workflow from the workflow engine 201 at block 733 andwaits for events from the agent workflow and the agent desktop 229(block 735). If the event is a contact request from the agent workflow(block 736), the agent subsystem method 730 checks to see if there is apending break request from the agent desktop (block 737). If not, theagent subsystem method 730 requests a contact for the agent from thedynamic ACD at block 739. Once the dynamic ACD returns a contact, theagent subsystem method 730 injects a handle contact event into the agentworkflow (block 740). When the agent or the contact terminates the callor the session, the agent subsystem method 730 receives a left-sessionevent from the corresponding contact workflow, i.e., the voice workflow,the email workflow, or the collaboration workflow, at block 741, andinjects the event into the agent workflow at block 742. The agentsubsystem method 730, in conjunction with the current session or call,also receives a wrap-up event from the agent workflow (block 743), whichit sends to the agent desktop (block 745). When the agent desktop hasdetermined that the agent is completely wrapped up the contact, theagent subsystem method 730 receives the end-wrap-up event from the agentdesktop at block 746, and in turn, injects the event into the agentworkflow at block 747. If a break request is pending (block 737), theagent subsystem method 730 waits until the agent workflow makes adecision on the break request (block 748). If allowed, the agentsubsystem method 730 waits at block 735 for an off-break event from theagent desktop. If not allowed, the agent subsystem method 730 requests acontact from the dynamic ACD at block 739.

If the agent subsystem method 730 receives a break request from theagent desktop (block 749), it sends an on-break event to the agentworkflow (block 770) and waits for a response, which it forwards to theagent desktop at block 751. If the break is allowed by the agentworkflow (block 752), the agent subsystem method 730 requests the agentbe removed from the agent list by the dynamic ACD at block 753 and waitsa block 735 for an off-break event from the agent desktop. When theoff-break event is received (block 754), the agent subsystem method 720injects the off-break event into the agent workflow at block 755 tocause the workflow to request a contact for the now-available agent.

If a logout event is received (block 756), the agent subsystem method730 requests the agent be removed from the agent list by the dynamic ACD(block 759) and injects a logout event into the agent workflow (block760). The handling of other events is illustrated generically at block757, where the event is injected into the agent workflow, and at block758, where the agent subsystem method 730 forwards any response receivedfrom the agent workflow to the agent desktop. One of skill in the artwill readily understand the processing necessary to handle differenttypes of events without further illustration.

An agent workflow method 770 for an agent workflow is now described inconjunction with FIG. 7C. The agent workflow method 770 begins byrequesting a contact for the agent from the agent subsystem at block771. The agent workflow method 770 then waits for agent events at block773. If a handle-contact event is received (block 753), the agent hasbeen allocated to a contact and the agent workflow method 770 waits fora left-session event from the corresponding contact workflow thatindicates the contact session has terminated (block 777). When theleft-session event arrives, the agent workflow method 770 sends awrap-up event to the agent subsystem at block 781 and waits for anend-wrap-up event that indicates the agent is now available (block 781).The agent workflow method 770 loops back to block 771 to request a newcontact for the agent.

If an on-break event is received by the agent workflow method 770 (block761), the agent workflow method 770 determines if the break can beallowed based on the status of the call center (block 785). In eithercase, a message is sent to the agent subsystem to notify the agentdesktop of the decision (block 785). If the break is allowed (block785), the agent workflow waits for an off-break event to be received atblock 786. If the break is not allowed, the agent workflow method 770loops to block 773 to wait for a contact.

If an agent logout event is received by the agent workflow method 770(block 779), the agent workflow method 770 terminates. In an embodimentnot shown, the agent logout event is a request that can be denied basedon the state of the contact center, such as when the contact center isoverloaded, or allowed at an appropriate time, such as when the agentworkflow requests a new contact. All other events are handled by theagent workflow method 770 as generically illustrated by block 791. Oneof skill in the art will readily understand the processing necessary tohandle different types of events within an agent workflow withoutfurther illustration.

It will be appreciated that the workflows described in conjunction withthe flow charts 4C, 5C, 6C and 7C are simplified examples of the actionsavailable through the workflow logic 207 and are not intended to limitthe invention to only those actions and sequences illustrated. Adetailed description of one embodiment of the workflow logic 207 and theworkflow actions is given in the next section.

In addition, one of skill in the art will readily conceive of alternatelogic flows with more or fewer processes or different processes thatachieve the results of these method and such alternatives are consideredwithin the scope of the invention. For example, instead of having thecontact workflows inject the left-session events directly into the agentworkflow, in one alternate embodiment, the contact workflow sends acontact-ended event to the contact subsystem and thence to theappropriate media router, which causes the router to send theleft-session event to the agent subsystem for injection into the agentworkflow. In another alternate embodiment, the termination of thecontact workflow causes the contact subsystem to send the contact-endedevent to the appropriate media router, causing the router to send theleft-session event to the agent subsystem and thence to the agentworkflow.

The particular methods performed by components of one embodiment of thedigital multimedia contact center of the present invention have beendescribed in terms of media-specific processing diagrams and flowcharts.The methods performed by a voice router, a voice subsystem, and workflowlogic for a voice contact have been shown by reference to flowcharts4A-C including all the acts from 401 until 407, from 421 until 443, andfrom 451 until 475, respectively. The methods performed by an emailescalator, an email subsystem, and workflow logic for an escalated emailcontact have been shown by reference to flowcharts 5A-C including allthe acts from 501 until 515, from 521 until 531, and from 541 until 549,respectively. The methods performed by a collaboration router, acollaboration subsystem, and workflow logic for a collaboration contacthave been shown by reference to flowcharts 6A-C including all the actsfrom 601 until 607, from 621 until 633, and from 641 until 649,respectively. The methods performed by an agent desktop, an agentsubsystem and workflow logic for an agent have been shown by referenceto flowcharts 7A-C including all the acts from 701 until 729, from 731until 760, and from 771 until 791, respectively.

Internet Contact Center (iCC) Implementation

In this section of the detailed description, a particular implementationof the invention is described. Companies subscribe to the services ofthe iCC to manage their customer contacts. The iCC is sited remotelyfrom the agents for the subscriber, who may be at various locations. Theagent desktops 229 are Web browser-based that connect to the agentsubsystem(s) 219 in the remote iCC. The subscriber's customers contactthe iCC directly through the Internet or POTS and are then routed to theappropriate agent desktop through a virtual private network. Thebrowser-based agent desktops enables the use of various plug-in appletsthat extend the basic capabilities of the agent desktop withoutextensive re-programming. Additionally, a combination Javaapplet/servlet can be used to implement the desktop manager describedpreviously.

Messaging

Communication between the workflow engine 201 and the media routers221/agent desktop 229 is handled through a set of interfaces using JavaRMI (remote method invocation). Three generic interfaces are provided ina messaging library. All contact workflow subsystems, e.g., voicesubsystem 213, collaboration subsystem 215 and email subsystem 217, arerequired to implement at least a generic contact service interface, suchas “ContactWorkflowServiceInterface” described below. All agent workflowsubsystems, e.g. the agent subsystem 219, are required to implement atleast a generic agent service interface, such as“AgentWorkflowServiceInterface” described below Each media router 221 isrequired to implement at least a generic media router interface, such as“MediaRouterInterface” described below. New interfaces specific to theservice requested can be defined that inherit from existing interfaces.Thus, for example, a voice service interface implements the genericcontact service interface along with interfaces for telephony commands.Global variables pass information between the workflow subsystems 205and the workflow logic 207. The global variables contain the valuesneeded by the workflow logic 207 in the context of a particularworkflow, and requests made by the workflow logic 207 to the workflowsubsystems 205 through various workflow steps described further below.

A media router 221 uses the ContactWorkflowServiceInterface of aparticular contact workflow subsystem to 1) start a contact workflow andreceive a contact identifier for the workflow, 2) inject an event intoan existing workflow identified by a contact identifier, and 3)determine if the contact workflow subsystem is handling a specifiedcontact. To start a workflow for a contact, a media router 221 invokes a“startWorkflow” method in the ContactWorkflowServiceInterface of thedesired contact workflow subsystem, passing in an identifier for themedia router interface of the media router (client), and the attributesof the contact (attributes), and receives an identifier for the newlycreated contact workflow in return (contactID), e.g.,

-   -   startWorkflow(client, contactID, attributes).

To inject an event into an existing workflow, a media router 221 invokesan “injectEvent” method in the ContactWorkflowServiceInterface of theappropriate contact workflow subsystem, identifying the contact workflow(contactID) and the event to be injected into the workflow (event),e.g.,

-   -   injectEvent(contactID, event).        To determine if a particular contact workflow subsystem is        handling a specific contact, a media router calls a        “handlesContact” method in the ContactWorkflowServiceInterface        of the contact workflow subsystem, passing in the identifier of        the contact workflow (contactID) and receives a boolean value in        return, e.g.,    -   handlesContact(contactId).

An agent desktop 229 uses the AgentWorkflowServiceInterface to 1) startan agent workflow and receive an agent identifier for the workflow, 2)inject an event into an existing workflow identified by an agentidentifier, and 3) determine if a particular agent workflow subsystem ismanaging a specified agent. As described previously, when multiple agentworkflow subsystem are present, an agent desktop is assigned to one ofthe agent workflow subsystems by a service manager. To start an agentworkflow, an agent desktop invokes a “startWorkflow” method in theAgentWorkflowServiceInterface of the appropriate agent workflowsubsystem, passing in the attributes of the agent (attributes), andreceives an identifier for the newly created agent workflow in return(agentID), e.g.,

-   -   startWorkflow(agentID, attributes).        To inject an event into an existing workflow, an agent desktop        invokes an “injectEvent” method in the        AgentWorkflowServiceInterface of the appropriate agent workflow        subsystem, identifying the agent workflow (agentID) and the        event to be injected into the workflow (event), e.g.,    -   injectEvent(agentID, event).

To determine if a particular agent workflow subsystem is handling aspecific agent, an agent desktop calls a “handlesAgent” method in theAgentWorkflowServiceInterface of the agent workflow subsystem, passingin the identifier of the agent workflow (agentID) and receives a booleanvalue in return, e.g.,

-   -   handles Agent(agentId).

The MediaRouterInterface allows contact workflow subsystems to routecontacts to the agents allocated by the dynamic ACD and to terminate acontact session. To route a contact to an agent, a contact workflowsubsystem invokes an “assignContactToAgent” method in theMediaRouterInterface of the appropriate media router, passing in theworkflow identifier for the contact (contactID) and the workflowidentifier for the agent (agentID) and receiving a boolean in returnthat indicates whether the routing was successful, e.g.,

-   -   assignContactToAgent(contactID, agentID).        To terminate a contact session, a contact workflow subsystem        invokes a “terminateContact” method in the        iCCMediaRouterInterface of the appropriate media router, passing        in the workflow identifier for the contact (contactID), e.g.,    -   terminateContact(contactID).

Database Unification Layer

The database unification layer 261 implements a unified schemaconsisting of information replicated from a number of different sourcesincluding the databases used by the third-party systems, and theinternal iCC database 231 as described previously. Each different sourceis defined in a sub-schema including:

-   -   Billing    -   Customer Relationship Management (CRM)    -   Entitlement (Billing option, maximum agents, maximum contacts, .        . . )    -   Provisioning (Agents, User IDs, Passwords, Classifications,        Skills, Proficiencies, . . . )    -   Business Logic (Priority Expressions, Attributes, Stored        Procedures, . . . )    -   Active State (Agent State, Session State, Contact State, Contact        Center State, Customer State).

The database unification layer provides access to the information in thevarious databases through Java classes, such as CRM, Provisioning,Entitlement, Rules, Contact Detail Record (CDR), Contact Center State.

The unified schema is synchronized with the vendor-specific sources by aset of database triggers. For instance, many conventional email systemsuse event handlers that watch for messages entering and changing state,and create and update CDR records as necessary, e.g. when an emailmessage is responded to or forwarded to another agent. Updating one ofthe sources with information in the unified schema is accomplishedthrough the Java classes.

One embodiment of a data structure 800 for a CDR is illustrated in FIG.5A. The contact represented by the CDR 800 is identified through acontact ID field 801. The media type through which the contact enteredthe iCC is specified in a media type field 803. Assuming the contact hasbeen classified, the classification for the contact is stored in acontact class ID field 805. If the iCC is implemented in conjunctionwith a standard customer relationship management system, the CRM caseidentifier is stored in a case ID field 807 to allow tracking of thecontact. The agent assigned to handle the contact is identified throughan assigned agent ID field 809. One or more fields 811 collectivelyrecord the history of the contact as it is process in the iCC. Eachfield 811 contains a contact state 813 and a timestamp 815. Thus, thechange in state of the contact can be tracked chronologically for thelife of the contact. Exemplary contact states used by the iCC are shownin Table 1 below and it will be appreciated that more or fewer statesmay be used. TABLE 1 iCC Contact States State Comment Initially CreatedEscalated Being Addressed On Hold Archived after wrap-up In WrapupTerminated no agent assigned Abandoned contact quits before being helpedQueued Demoted

One embodiment of a data structure 820 for an agent record isillustrated in FIG. 5B. The agent represented by the agent record 820 isidentified by an agent ID field 821. Assuming the agent has beenclassified, the classification for the agent is stored in an agent classED field 823. The contact identifier for the current contact the agentis handling is stored in an assigned contact ID field 825. One or morefields 827 collectively record the history of the agent while he or sheis logged into the iCC. Each field 827 contains an agent state 829 and atimestamp 831. Thus, the change in state of the agent can be trackedchronologically during the workday of the agent. The agent states usedby the iCC are shown in Table 2 below and it will be appreciated thatmore or fewer states may be used. TABLE 2 iCC Agent States State CommentLogged Out On Break Available Logged in and not assigned a contact BusyWrap Up Post-contact processing

Soft ACD)

The iCC uses a software-implemented ACD to manage the allocation of allcontacts and agents. The Soft ACD exists as a set of stored proceduresin the contact center database that refer to special database tablesused as the unordered lists of available agents and waiting contacts.The unordered lists may be further logically subdivided, e.g., byclassification.

The Soft ACD also loads business logic and provisioning information(described below) when required. Each classification within theorganization (e.g., Sales, Support, Customer Service, etc.) isassociated with a particular set of business logic. If any of thisinformation changes, the Soft ACD is notified, it reloads thisinformation, and immediately applies the new information to the iCC.While it is running, the Soft ACD maintains the state (classifications,requirements, and attributes) of each entry in the lists.

When a running workflow requests an agent or contact, the appropriatesubsystem passes the request onto the Soft ACD as previously described.The Soft ACD determines the best match for the agent or contact byfiltering the opposite list on classification and in light of anyrequirements specified in the request, and prioritizing the filteredentries using one or more “priority expressions.” Each priorityexpression contains a set of weighted contact/agent attributes thatproduce a priority from 0 to 100 when an entry is evaluated. Theattributes and their weights exist as classes in the business logicsub-schema in the database unification layer and are described next. Itshould be noted that the Soft ACD dynamically performs the filtering andprioritizing anew for each request for a match.

While a contact or agent is waiting on a list, the requesting workflowis free to continue executing, but when an actual allocation occurs, aresource allocator notifies the corresponding subsystem, which theninterrupts the requesting workflow to route the contact.

Business Logic

The business logic used by the iCC for a subscriber is defined throughan email manager, a workflow editor, and an administrative interface.The email manager is used to create email rules that route emailcontacts into various predefined mailboxes. These rules may referencetext in the from, to, subject and body of the message as well as makedatabase queries. Mailbox queues are separate message areas maintainedby the email server. Agents retrieve messages from these queues.Individual queues can be set up, e.g., for each agent or for separateproducts, and additions or deletions to the existing set of queues canbe made as necessary. For example, the subscriber could initially defineone queue per product per classification (“SalesPrinters” or“SupportPrinters”) and add more as business crows. The systemadministrator grants access to these queues on a per agent basis. Anadditional queue is defined for escalated email messages as previouslydescribed. After defining the queues, the rules which route messagesinto those queues are defined. Rules can also be specified that demotecertain email messages into self-service by routing them to theauto-responder function.

The workflow editor defines a workflow for handling a contact or anagent. A subscriber may defined any number of agent and contactworkflows through the workflow editor. For example, each agent mighthave a particular workflow based on the agent's login identifier. Theworkflows and their related invocation information are stored forreference by the workflow engine 201 in an LDAP directory server orother directory structure that defines hierarchical directory entries.For example, a subscriber might define the following hierarchy in whichthe entries at levels (a) and (b) are the invocation information for theworkflows specified at levels (i). 1) asubscriber.com a) iCC i)configurations (1) wfVoice (a) 1234 (i) Workflow “Salescontact.WFE” (b)1000 (i) Workflow “SupportContact.WFE” (2) wfEmail (a)sales@asubscriber.com (i) Workflow “Salescontact.WFE” (b)support@asubscriber.com (i) Workflow “SupportContact.WFE” (3)wfWebCollaboration (a) http://asubscriber.com/sales (i) Workflow“SalesContact.WFE” (b) http://asubscriber.com/support (i) Workflow“SupportContact.WFE”

The administrative interface uses the classes in the business logicsub-schema to define logins, passwords, agent skills and proficiencies,call center classifications, service level objectives, emailoverdue/escalation thresholds, priority expressions, attributes,attribute weightings, etc. When the administrative interface starts up,it reads the system and subscriber business logic from the databaseusing the business logic classes. When entities are changed, therelevant data is written back to the database through these samebusiness logic classes. The administrative interface presents thesubscriber with various graphical user interface (GUT) screen to assistthe user in defining the subscriber business logic.

Through one of the GUI screens, the subscriber sets up the call centerclassifications, which define gross distinctions between contacts orbetween agents. The same set of classifications is used for bothcontacts and agents. Within a particular classification, the subscriberdefines service level objectives for each media type. Service levelobjectives are defined as the percentage of contacts of a particularmedia type which must be handled in a specific time. Thus, the GUIscreen for defining service level objectives presents the user with alist of the media types, an input area for a percentage value, and aninput area for an elapsed time value.

Each agent has a set of skills and a proficiency within each skill,which are specified and modified through the administrative interface.When a contact requests an agent, certain skills/proficiencies may bespecified as contact requirements. The requirements may also includeaging information for relaxing those requirements after a certain amountof time has elapsed without the contact being helped. For instance, theaging information might say that for the first 30 seconds a particularvoice call will accept a proficiency of 5 for a particular skill, after30 seconds a proficiency of 2 will be acceptable. This is referred to as“aging” a requirement.

The iCC comes pre-configured with a number of system defined attributesincluding

-   -   TimeInQueue—the time a contact has been waiting for a resource        (available through a database stored procedure and calculated on        the fly by the Software ACD.)    -   IsEmail—is this contact an email?    -   IsVoice—is this contact a voice call?    -   IsCollaboration—is this contact a web collaboration?    -   MediaServiceLevel—percentage of contacts of this media type        handled within the specified media-specific service objective    -   LastAgent—User ID of last agent this customer talked to.

Subscriber-defined attributes that determine a contact-agent match arespecified through the administrative interface. Attributecharacteristics include name, type (Call Center, Agent, Contact), valuetype (numeric, symbolic), values, default values, value normalization,and corresponding stored procedure. The subscriber defines the set ofattributes using a GUI screen that prompts the user for input bydisplaying permitted choices or through visual clues, such as a choiceof normalization curves. The stored procedure for an attributecalculates a value for the attribute when the attribute is used in apriority expression. The stored procedures can have been previouslycreated or may be created when the attribute is created.

The agent and contact priority expressions are created through agraphical user interface that allows an administrator to drag-and-dropdesired attributes into an expression and set their weighting throughslider bars. There is one priority expression for agents and one forcontacts within each classification. When a new priority expression isspecified, a new stored procedure is generated in a database scriptinglanguage, such as PL/SQL, compiled, and added to the database. Oneexemplary priority expression is shown in the following pseudocode:

For each attribute:

-   -   Call the attribute's stored procedure passing ContactID and        CustomerID;    -   If value returned is −1, use the attribute's default value;    -   If the attribute is symbolic, convert to a normalized value;    -   Multiply result by specified weighting and add this to the        accumulated total.

For a more specific example, assume a subscriber specified twoclassifications “Sales” and “Support” and a contact attribute called“BusinessValue” (i.e., the value of this contact to the subscriber'sbusiness). For the Sales classification, the subscriber created acontact priority expression of:BusinessValue*0.2+TimeInQueue*0.1+IsEmail*0.1+IsVoice*0.4+IsCollaboration*0.2and for the Support classification, a contact priority expression of:BusinessValue*0.1+TimeInQueue*0.1+IsEmail*0.1+IsVoice*0.6+IsCollaboration*0.1.

When the Soft ACD is prioritizing the waiting contacts for assignment toan agent, it evaluates the expression for each contact of theappropriate classification by calling the stored procedure associatedwith the BusinessValue attribute and multiplying the value returned by0.2 for a Sales contact or 0.1 for a Support contact. The weightedbusiness value of the contact is then added to the appropriatelyweighted values of the system defined attributes to calculate thepriority for the contact.

The Soft ACD can prioritize each agent/contact before deciding on theappropriate match or alternately may employ an optimization scheme inwhich the first agent/contact that reaches a pre-determined priorityvalue is chosen.

Provisioning Information

The underlying components of iCC must set up and configured before thecenter is ready for operation. The email manager allows administratorsto define agents, agent passwords, mailboxes, as well as the rules bywhich contacts are routed to these mailboxes. An administrationinterface to the collaboration server is used to define agents, agentpasswords, and agent extensions. The telephony server is set up bycreating dial plans and associating phone numbers with applications, andagents with phone extensions.

Workflow Engine

The iCC uses workflows to process contact, manage agents, and controlthe overall contact center functions. Workflow steps are the basicbuilding blocks of control in the iCC workflow engine. The workflowsteps available to a designer depend on the type of workflow beingdeveloped. For example, voice workflow steps include answer, collectdigits, and record. Exemplary agent workflow steps include allow break,handle contact, and wrap up. Some workflow steps are applicable to allcontact workflows, such as classify contact, request agent, and delivercontact. Control steps, e.g. end, wait, and if, are available for allworkflows, along with a send email step. Additional steps for thecontact and agent workflows will be readily apparent to one of skill inthe art.

Instead of hard-coded scripts typically used to implement workflows, theiCC workflow engine 900 dynamically creates a script for a workflow fromtwo files as described in conjunction with FIG. 9A. Definitions forprototype nodes 911, 913, 915, 917, 919 are stored in a template file903. Each node is associated with workflow code that implements ahigh-level, compound script action, such as “play menu withinterruptible prompts” or “play music until an agent is available,” thatare available to the workflow engine 900. The script actions are builtfrom workflow steps. For ease of explanation, the script actionsrepresented in FIG. 9A are simple, single commands, e.g., node A 911represents the function “if(x boolean y),” where “x,” “boolean,” and “y”are parameters that will be replaced by values specified by an instanceof the node A 911. It will be appreciated that the invention is notlimited by the example or by the workflow steps shown herein.

When in configuration mode 901, the workflow engine 900 (or a supportingapplication) enables a user, such as a system administrator, to create aworkflow 905 by selecting the appropriate nodes from the template file903, specifying the appropriate values for the parameters in the scriptcommand, and linking the nodes together to form a directed graph thatrepresents the desired workflow. Thus, for example, when node A′ 921 isexecuted, the function “if(number<10)” is evaluated, with a true resultcausing edge 931 to be followed to execute node B′ 923 and a falseresult causing edge 933 to be followed to execute node C′ 925. Aconfiguration file 907 is created from the directed graph and specifiesthe structure for the workflow 905. The configuration file 907 containsan identifier for each corresponding prototype node, along with thevalues, edge information and other settings (configuration data)associated with each node in the graph. It will be appreciated that anyof the common input methodologies used to obtain user input can beemployed to create the directed graph for the workflow, including agraphical user interface that gives the user drag-and-drop capabilitiesto allow the placement and rearrangement of nodes and edges, and dialogboxes that request the appropriate parameters.

When the workflow 905 is to be executed by the workflow engine 900 inrun-time mode 909, the workflow engine 900 references the configurationfile 907 and reconstructs the directed graph for the workflow 905 inmemory by merging the corresponding prototype nodes from the templatefile 903 with the configuration data associated with the nodes in theconfiguration file 907. The workflow engine initiates a new thread ofexecution to execute the workflow script represented by the directedgraph. Thus, the workflow engine 900 abstracts out the code andconnectors when the user creates a workflow and subsequentlyreconstructs the workflow from the abstractions when it is to beexecuted.

Unlike typical workflow implementations, all iCC workflow steps canexecute asynchronously by storing its result to a prioritized messagequeue in its thread of execution. Additionally, step may spawn anotherexecution thread to create a multithreaded workflow. Similar classes ofsteps may share one queue with one execution thread for all requests ofthat type from a single workflow or across workflows. As previouslydescribed, various workflow steps request a service from a subsystem.The subsystems inject service events into the workflow by placing eventnotifications in the message queue. The retrieval of messages from thequeue is implemented using three special workflow steps: RegisterEvent,UnRegisterEvent, and GetMessage.

RegisterEvent and UnRegisterEvent modify handlers for events. Bydefault, an event is handled in-line in the node that caused the event.RegisterEvent specifies a target node that will handle the event instead(referred to as “chaining”). Handlers are stacks; when a handler isregistered using RegisterEvent, the target node for that event is pushedonto the stack; when UnRegisterEvent is called, the stack is popped.

The GetMessage step fetches a message from the queue. When the messageis an event notification for which a registration (via RegisterEvent)has been made, the workflow engine branches to the target node to handlethe event. If the event was not explicitly registered, the current nodeis pushed onto the stack to handle the event.

An example of the asynchronous processing of the workflow steps isillustrated in FIG. 9B. A workflow 904 begins at node AA 941. As part ofits code, node AA 941 requests (arrow 951) that the database subsystemretrieve a record from the unified database 957. When the record isretrieved, the database subsystem stores (arrow 953) an eventnotification in a message queue 959. Instead of waiting for the databasesubsystem to retrieve the record, the node AA 941 registers itself asthe target node to handle the event. The workflow continues processing,executing node BB 943 and node CC 945, before reaching node DD 947,which requests (arrow 955) messages from a queue 959. Assuming that theevent notification is in the queue 959, it will be returned (arrow 955)to node DD 947, which in turns, returns (edge 967) the eventnotification to node AA 941 for handling. Once node AA 941 has receivedthe record, it passes (edge 969) it onto node EE 949 for furtherprocessing.

In one embodiment, the template and configuration files are documents,with the nodes represented by XML elements, and the code andconfiguration information stored as XML attributes for the correspondingXML elements. The code and configuration information are written in theJPython scripting language. A JPython-aware execution proxy merges theinformation from the template and configuration files, and provides aninterface between the thread of execution for the workflow and theactual workflow steps. Because the execution proxy insulates the threadof execution from the workflow steps, steps may use multiple scriptinglanguages simultaneously, allowing the developer of the prototype nodesto chose the best code to perform a given function.

Operating Environment

The following description of FIGS. 10A-B is intended to provide anoverview of computer hardware and other operating components suitablefor implementing the invention, but is not intended to limit theapplicable environments. One of skill in the art will immediatelyappreciate that the invention can be practiced with other computersystem configurations, including hand-held devices, multiprocessorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, and the like. Theinvention can also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network.

FIG. 10A shows several computer systems 1 that are coupled togetherthrough a network 3, such as the Internet. The term “Internet” as usedherein refers to a network of networks which uses certain protocols,such as the TCP/IP protocol, and possibly other protocols such as thehypertext transfer protocol (HTTP) for hypertext markup language (HTML)documents that make up the World Wide Web (web). The physicalconnections of the Internet and the protocols and communicationprocedures of the Internet are well-known to those of skill in the art.Access to the Internet 3 is typically provided by Internet serviceproviders (ISP), such as the ISPs 5 and 7. Users on client systems, suchas client computer systems 21, 25, 35, and 37 obtain access to theInternet through the Internet service providers, such as ISPs 5 and 7.Access to the Internet allows users of the client computer systems toexchange information, receive and send e-mails, and view documents, suchas documents which have been prepared in the HTML format. Thesedocuments are often provided by web servers, such as web server 9 whichis considered to be “on” the Internet. Often these web servers areprovided by the ISPs, such as ISP 5, although a computer system can beset up and connected to the Internet without that system being, also anISP as is well known in the art.

The web server 9 is typically at least one computer system whichoperates as a server computer system and is configured to operate withthe protocols of the World Wide Web and is coupled to the Internet.Optionally, the web server 9 can be part of an ISP which provides accessto the Internet for client systems. The web server 9 is shown coupled tothe server computer system 11 which itself is coupled to web content 10,which can be considered a form of a media database. It will beappreciated that while two computer systems 9 and 11 are shown in FIG.10A, the web server system 9 and the server computer system 11 can beone computer system having different software components providing theweb server functionality and the server functionality provided by theserver computer system 11 which will be described further below.

Client computer systems 21, 25, 35, and 37 can each, with theappropriate web browsing software, view HTML pages provided by the webserver 9. The ISP 5 provides Internet connectivity to the clientcomputer system 21 through the modem interface 23 which can beconsidered part of the client computer system 21. The client computersystem can be a personal computer system, a network computer a Web TVsystem, or other such computer system. Similarly, the ISP 7 providesInternet connectivity for client systems 25, 35, and 37, although asshown in FIG. 1A, the connections are not the same for these threecomputer systems. Client computer system 25 is coupled through a modeminterface 27 while client computer systems 35 and 37 are part of a LAN.While FIG. 10A shows the interfaces 23 and 27 as generically as a“modem,” it will be appreciated that each of these interfaces can be ananalog modem, ISDN modem, cable modem, satellite transmission interlace(e.g. “Direct PC”), or other interfaces for coupling a computer systemto other computer systems. Client computer systems 35 and 37 are coupledto a LAN 33 through network interfaces 39 and 41, which can be Ethernetnetwork or other network interfaces. The LAN 33 is also coupled to agateway computer system 31 which can provide firewall and other Internetrelated services for the local area network. This gateway computersystem 31 is coupled to the ISP 7 to provide Internet connectivity tothe client computer systems 35 and 37. The gateway computer system 31can be a conventional server computer system. Also, the web serversystem 9 can be a conventional server computer system.

Alternatively, as well-known, a server computer system 43 can bedirectly coupled to the LAN 33 through a network interface 45 to providefiles 47 and other services to the clients 35, 37, without the need toconnect to the Internet through the gateway system 31.

FIG. 10B shows one example of a conventional computer system that can beused as a client computer system of a server computer system or as a webserver system. It will also be appreciated that such a computer systemcan be used to perform many of the functions of an Internet serviceprovider, such as ISP 105. The computer system 51 interfaces to externalsystems through the modem or network interface 53. It will beappreciated that the modem or network interface 53 can be considered tobe part of the computer system 51. This interface 53 can be an analogmodem, ISDN modem, cable modem, token ring interface, satellitetransmission interface (e.g. “Direct PC”), or other interfaces forcoupling a computer system to other computer systems. The computersystem 51 includes a processor 55, which can be a conventionalmicroprocessor such as an Intel Pentium microprocessor or Motorola PowerPC microprocessor. Memory 59 is coupled to the processor 55 by a bus 57.Memory 59 can be dynamic random access memory (DRAM) and can alsoinclude static RAM (SRAM). The bus 57 couples the processor 55 to thememory 59 and also to non-volatile storage 65 and to display controller61 and to the input/output (I/O) controller 67. The display controller61 controls in the conventional manner a display on a display device 63which can be a cathode ray tube (CRT) or liquid crystal display. Theinput/output devices 69 can include a keyboard, disk drives, printers, ascanner, and other input and output devices, including a mouse or otherpointing device. The display controller 61 and the I/O controller 67 canbe implemented with conventional well known technology. A digital imageinput device 71 can be a digital camera which is coupled to an I/Ocontroller 67 in order to allow images from the digital camera to beinput into the computer system 51. The non-volatile storage 65 is oftena magnetic hard disk, an optical disk, or another form of storage forlarge amounts of data. Some of this data is often written, by a directmemory access process, into memory 59 during execution of software inthe computer system 51. One of skill in the art will immediatelyrecognize that the term “computer-readable medium” includes any type ofstorage device that is accessible by the processor 55 and alsoencompasses a carrier wave that encodes a data signal.

It will be appreciated that the computer system 51 is one example ofmany possible computer systems which have different architectures. Forexample, personal computers based on an Intel microprocessor often havemultiple buses, one of which can be an input/output (I/O) bus for theperipherals and one that directly connects the processor 55 and thememory x59 (often referred to as a memory bus). The buses are connectedtogether through bridge components that perform any necessarytranslation due to differing bus protocols.

Network computers are another type of computer system that can be usedwith the present invention. Network computers do not usually include ahard disk or other mass storage, and the executable programs are loadedfrom a network connection into the memory 59 for execution by theprocessor 55. A Web TV system, which is known in the art, is alsoconsidered to be a computer system according to the present invention,but it may lack some of the features shown in FIG. 10B, such as certaininput or output devices. A typical computer system will usually includeat least a processor, memory, and a bus coupling the memory to theprocessor.

It will also be appreciated that the computer system 51 is controlled byoperating system software which includes a file management system, suchas a disk operating system, which is part of the operating systemsoftware. One example of an operating system software with itsassociated file management system software is the Windows family ofoperating systems from Microsoft Corporation of Redmond, Wash., and theassociated file management systems. The file management system istypically stored in the non-volatile storage 65 and causes the processor55 to execute the various acts required by the operating system to inputand output data and to store data in memory including storing files onthe non-volatile storage 65.

CONCLUSION

A tiered service model providing escalation and de-escalation ofcontacts in a multimedia digital contact center has been described.Although specific embodiments have been illustrated and describedherein, it will be appreciated by those of ordinary skill in the artthat any arrangement which is calculated to achieve the same purpose maybe substituted for the specific embodiments shown. This application isintended to cover any adaptations or variations of the presentinvention.

The terminology used in this application with respect to networks ismeant to include all of network environments, including privatewide-area networks and local-area networks. Therefore, it is manifestlyintended that this invention be limited only by the following claims andequivalents thereof.

1. A digital multimedia contact center comprising: a workflow engineoperable for executing a workflow for a contact that specifiesprocessing of the contact; a set of media routers coupled to theworkflow engine each media router operable for sending a contactassociated with a particular media type to the workflow engine andoperable for routing the contact to an agent if an agent is allocated tothe contact; a dynamic automatic contact distributor coupled to theworkflow engine and operable for allocating an agent to the contact whenrequested by the workflow and for returning an identifier for theallocated agent to the workflow engine; an agent desktop coupled to theworkflow engine and operable for receiving a contact routed by a mediarouter and presenting the contact to the allocated agent for processing;and a database coupled to the workflow engine for recording theprocessing of the contact by the allocated agent.
 2. The digitalmultimedia contact center of claim 1, wherein the particular media typesare selected from the group consisting of analog voice, digital voice,video, email, fax, and Web.
 3. The digital multimedia contact center ofclaim 1, wherein the workflow engine is further operable for executing aworkflow for an agent that controls the contacts allocated to the agent.4. The digital multimedia contact center of claim 1, wherein theworkflow engine comprises: a set of contact workflow subsystems, eachcontact workflow subsystem operable for starting a workflow for acontact associated with a particular media type and coupled to the mediarouter associated with the particular media type; an agent workflowsubsystem coupled to the agent desktop and operable for starting aworkflow for an agent logged into the agent desktop; and workflow logicfor executing the workflows and coupled to the workflow subsystemsthrough a message passing layer.
 5. The digital multimedia contactcenter of claim 1, wherein the workflow engine is further operable forcreating a directed graph that represents a workflow.
 6. The digitalmultimedia contact center of claim 5, wherein the workflow enginecreates the directed graph from a template file defining prototype nodesrepresenting steps and a configuration file for the workflow thatdefines a structure for the graph.
 7. The digital multimedia contactcenter of claim 1, wherein each of the media routers is coupled to anexternal system, each external system operable for receiving, from acommunications channel, contacts having the particular media associatedwith the coupled media router, each external system being associatedwith a particular media type and further operable for routing a contactto the agent desktop when instructed by the coupled media router.
 8. Thedigital multimedia contact center of claim 7, wherein one of the mediarouters is an email escalator coupled to an email server, the emailescalator operable for escalating a email contact from a deferredservice tier to an immediate service tier based on pre-determined emailescalation criteria.
 9. The digital multimedia contact center of claim7, wherein one of the media routers is a collaboration router coupled toa web server, the collaboration router operable for escalating a webcontact from a self-service service tier to an immediate service tier inresponse to user input.
 10. The digital multimedia contact center ofclaim 7, wherein one of the media routers is a voice router coupled to avoice server, the voice router operable for de-escalating a voicecontact from an immediate service tier to a self-service service inresponse to contact information and further operable for escalating avoice contact from the self-service tier to the immediate service tierin response to user input.
 11. The digital multimedia contact center ofclaim 7 further comprising a database unification layer coupled betweenthe database and the workflow engine and further coupled to the externalsystems to integrate information maintained by the external systems andthe database.
 12. The digital multimedia contact center of claim 11,wherein the workflow engine further comprises a database subsystem tointerpret database accesses made by a workflow into accesses for thedatabase unification layer.
 13. The digital multimedia contact center ofclaim 1, wherein the dynamic automatic contact distributor maintains anunordered list of waiting contacts and an unordered list of availableagents to allocate a contact to an agent.
 14. The digital multimediacontact center of claim 13, wherein the dynamic automatic contactdistributor allocates a new contact to an agent by evaluating theunordered list of available agents using a first expression of weightedattributes.
 15. The digital multimedia contact center of claim 14,wherein the dynamic automatic contact distributor places the new contactin the unordered list of waiting contacts if no agent in the unorderedlist of available agents satisfies the first expression.
 16. The digitalmultimedia contact center of claim 14, wherein the dynamic automaticcontact distributor allocates a newly available agent to a contact byevaluating the unordered list of waiting contacts using a secondexpression of weighted attributes.
 17. The digital multimedia contactcenter of claim 16, wherein the dynamic automatic contact distributorplaces the newly available agent in the unordered list of availableagents if no contact in the unordered list of waiting contacts satisfiesthe second expression.
 18. A computer-readable medium havingcomputer-executable modules comprising: a workflow engine to execute aworkflow for a contact that specifies processing of the contact: aplurality of media routers for coupling to the workflow engine to send acontact associated with a particular media type to the workflow engineand to route the contact to an agent if an agent is allocated to thecontact; and a dynamic automatic contact distributor for coupling to theworkflow engine to allocate an agent to the contact when requested bythe workflow and return an identifier for the allocated agent to theworkflow engine.
 19. The computer-readable medium of claim 18 havingfurther computer-executable modules comprising: a database for couplingto the workflow engine to record the processing of the contact by theallocated agent.
 20. The computer-readable medium of claim 19 havingfurther computer-executable modules comprising: a database unificationlayer that integrates information maintained by the database and aplurality of external systems for particular media types.
 21. Thecomputer-readable medium of claim 20 having further computer-executablemodules comprising: a database subsystem to interpret database accessesmade by a workflow into accesses for the database unification layer. 22.The computer-readable medium of claim 18 having furthercomputer-executable modules for the workflow engine comprising: aplurality of contact workflow subsystems to a workflow for a contactassociated with a particular media type and for coupling to the mediarouter associated with the particular media type; an agent workflowsubsystem for coupling to an agent desktop and to start a work-flow foran agent logged into the agent desktop; and workflow logic to executethe workflows and for coupling to the workflow subsystems through amessage passing layer.
 23. The computer-readable medium of claim 18,wherein each of the media routers is further operable for coupling to anexternal system that receives, from a communications channel, contactshaving the particular media associated with the coupled media router,each external system being associated with a particular media type toroute a contact to an agent desktop when instructed by the coupled mediarouter.
 24. The computer-readable medium of claim 18, wherein one of themedia routers is an email escalator for coupling to an email server toescalate a email contact from a deferred service tier to an immediateservice tier based on pre-determined email escalation criteria.
 25. Thecomputer-readable medium of claim 18, wherein one of the media routersis a collaboration router for coupling to a web server to escalate a webcontact from a self-service service tier to an immediate service tier inresponse to user input.
 26. The computer-readable medium of claim 18,wherein one of the media routers is a voice router for coupling to avoice server to de-escalate a voice contact from an immediate servicetier to a self-service service in response to contact information and toescalate a voice contact from the self-service tier to the immediateservice tier in response to user input.
 27. The computer-readable mediumof claim 18, wherein the dynamic automatic contact distributor maintainsan unordered list of waiting contacts and an unordered list of availableagents to allocate a contact to an agent.
 28. The computer-readablemedium of claim 27, wherein the dynamic automatic contact distributorallocates a new contact to an agent by evaluating the unordered list ofavailable agents using a first expression of weighted attributes. 29.The computer-readable medium of claim 28, wherein the dynamic automaticcontact distributor places the new contact in the unordered list ofwaiting contacts if no agent in the unordered list of available agentssatisfies the first expression.
 30. The computer-readable medium ofclaim 28, wherein the dynamic automatic contact distributor allocates anewly available agent to a contact by evaluating the unordered list ofwaiting contacts using a second expression of weighted attributes. 31.The computer-readable medium of claim 30, wherein the dynamic automaticcontact distributor places the newly available agent in the unorderedlist of available agents if no contact in the unordered list of waitingcontacts satisfies the second expression.
 32. A computer-readable mediumhaving computer-executable modules comprising: an agent desktop forcoupling to a workflow engine to receive a contact routed by a mediarouter and to present the contact to an agent logged into the agentdesktop for processing. 33.-44. (canceled)
 45. A computer-readablemedium having a data structure for a contact detail record comprising: acontact ID field containing data representing a contact identifier for acontact associated with the contact detail record; a media type fieldcontaining data representing a media type for the contact identified bythe contact ID field; a contact class ID containing data representing aclassification for the contact identified by the contact ID field; anassigned agent ID containing data representing an agent assigned tohandle the contact identified by the contact ID field; and a pluralityof contact state fields, each contact state field comprising: a contactstate field containing data representing a state of the contactidentified by the contact ID field at a particular time; and a timestampfield containing data representing the particular time associated withdata in the contact state field.
 46. The computer readable medium ofclaim 45, wherein the data structure further comprises: a ease ID fieldcontaining data representing a contact resource management caseidentifier for the contact identified by the contact ID field.
 47. Acomputer readable having) a data structure for an agent recordcomprising: an agent ID field containing data representing an agentidentifier for an agent associated with the agent record; an agent classID field containing data representing a classification for the agentidentified by the agent ID field; an assigned contact ID fieldcontaining data representing an identifier for a contact assigned to theagent identified by the agent ID field; and a plurality of agent statefields, each agent state field comprising: an agent state fieldcontaining data representing a state of the agent identified by theagent ID field at a particular time; and a timestamp field containingdata representing the particular time associated with data in the agentstate field.
 48. A method of communicating between a media router and acontact workflow subsystem in a digital multimedia contact centercomprising: issuing, by the media router to the contact workflowsubsystem a start workflow call including an identifier for the mediarouter and attributes of a contact; and returning by the contactworkflow subsystem to the media router, an identifier for a workflow forthe contact in response to receiving the start workflow call.
 49. Themethod of claim 48 further comprising: issuing, by the media router tothe contact workflow subsystem, an inject event call including theidentifier for the workflow and an event to be injected into theworkflow.
 50. The method of claim 48 further comprising: issuing, by themedia router to the contact workflow subsystem a handles contact callincluding an identifier for a contact workflow; and returning, by thecontact workflow subsystem to the media router, a response indicating ifthe contact workflow subsystem is handling the contact workflow.
 51. Themethod of claim 48 further comprising: issuing, by the contact workflowsubsystem to the media router, an assign contact to agent call includingan identifier for a workflow for a contact and an identifier for aworkflow for an agent and returning, by the media router to the contactworkflow subsystem, a response indicating if the contact was routed tothe agent.
 52. The method of claim 48 further comprising: issuing, bythe contact workflow subsystem to the media router, a terminate contactcall including an identifier for a contact workflow.
 53. A method ofcommunicating between a media router and an agent workflow subsystem ina digital multimedia contact center comprising: issuing, by the mediarouter to the agent workflow subsystem, a start workflow call includingattributes of an agent; and returning, by the agent workflow subsystemto the media router, an identifier for a workflow for the agent inresponse to receiving the start workflow call.
 54. The method of claim53 further comprising: issuing by the media router to the agent workflowsubsystem, an inject event call including the identifier for theworkflow and an event to be injected into the workflow.
 55. The methodof claim 53 further comprising: issuing, by the media router to theagent workflow subsystem, a handles agent call including an identifierfor an agent workflow; and returning, by the agent workflow subsystem tothe media router, a response indicating if the agent workflow subsystemis handling the agent workflow.
 56. A method of operating a multimediacontact center comprising: receiving, by a media router, a contact of amedia type particular to the media router; sending, by the media router,the contact to a workflow subsystem particular to the media type of thecontact; initiating, by the workflow subsystem, a workflow for thecontact; sending, by the workflow for the contact, a request for anagent to handle the contact to the workflow subsystem; requesting, bythe workflow subsystem, an agent from an automatic contact distributor;allocating, by the automatic contact distributor, an agent to thecontact; sending, by the automatic contact distributor, an identifierfor the agent allocated to the contact to the workflow subsystem;receiving, by the workflow subsystem, the identifier for the agent;sending, by the workflow subsystem, the identifier for the agent to themedia router; and routing, by the media router, the contact to the agentallocated to the contact.
 57. The method of claim 56 further comprising:receiving, by an agent desktop, a login by an agent; sending, by theagent desktop, agent information to an agent subsystem; receiving, bythe agent subsystem, the agent information; initiating, by the agentdesktop, a workflow for the agent; sending, by the workflow for theagent, a request for a contact to the agent subsystem, requesting, bythe agent subsystem, a contact from the automatic contact distributor;allocating, by the automatic contact distributor, the agent to acontact; sending, by the automatic contact distributor, an identifierfor the contact allocated to the agent to the agent subsystem;receiving, by the agent subsystem, the identifier for the contact,sending, by the agent subsystem, an indication to the workflow that theagent has been allocated to a contact; receiving, by the agent desktop,a contact from a media router; and sending, by the agent desktop, thecontact to an appropriate subsystem for processing.
 58. A computerizedserver for a digital multimedia contact center comprising: a processingunit; a memory coupled to the processing unit through a bus; a networkinterface coupled to the processing unit through the bus and furtheroperable for coupling to a network; a media router executed from thememory to cause the processing unit to receive a contact of a media typeparticular to the media router from the network interface, to send thecontact to a workflow subsystem particular to the media type of thecontact, and to route the contact to an agent identified by the workflowsubsystem through the network interface the workflow subsystem executedfrom the memory to cause the processing unit to initiate a contactworkflow for the contact received from the media router, to request anagent from an automatic contact distributor, to receive an identifierfor an agent from the automatic contact distributor and to send theidentifier for the agent to the media router; the contact workflowexecuted from the memory to cause the processing unit to send a requestfor an agent to handle the contact to the workflow subsystem; and theautomatic contact distributor to cause the processing unit to allocatean agent to the contact and to send the identifier for the agentallocated to the contact to the workflow subsystem.
 59. The computerizedserver of claim 58, wherein the automatic contact distributor is furtheroperable to cause the processing unit to receive a request for a contactfrom an agent subsystem and to send an identifier for the contactallocated to the agent to the agent subsystem, and further comprising:the agent subsystem executed from the memory to cause the processingunit to receive agent information from the network interface, toinitiate an agent workflow for the agent, to request a contact from theautomatic contact distributor, to receive the identifier for the contactform the automatic contact distributor and to send an indication to theagent workflow that the agent has been allocated to a contact; and theagent workflow executed from the memory to cause the processing unit tosend a request for a contact to the agent subsystem.
 60. A computerizedclient for a multimedia contact center comprising: a processing unit; amemory coupled to the processing unit through a bus; a network interfacecoupled to the processing unit through the bus and further operable forcoupling to a network; and an agent desktop executed from the memory tocause the processor to receive a login by an agent, to send agentinformation to an agent subsystem through the network interface, toreceive a contact from the network interface, and to send the contact toan appropriate subsystem for processing.